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Foreword 



This Technical Specification (TS) was been produced by ETSI Technical Committee Telecommunications and Internet 

converged Services and Protocols for Advanced Networking (TISPAN) and originally published as 

ETSI TS 183 047 [6]. It was transferred to the 3"* Generation Partnership Project (3GPP) in December 2007. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the stage three Protocol Description of the Advice Of Charge (AOC) service, based on 
stage 1 and 2 of the ISDN Supplementary Service Advice Of Charge for all calls (permanent mode). It provides the 
protocol details in the IP Multimedia (IM) Core Network (CN) subsystem based on the Session Initiation Protocol (SIP) 
and the Session Description Protocol (SDP). 

Three AOC services exist: 

a) Charging information at communication set-up time (AOC-S) 

The AOC-S service enables a user to receive information about the charging rates at communication set-up time 
and also to receive further information during the communication if there is a change of charging rates. 

b) Charging information during the communication (AOC-D) 

The AOC-D service enables a user to receive information on the recorded charges for a communication during 
the active phase of the communication. 

c) Charging information at the end of the communication (AOC-E) 

The AOC-E service enables a user to receive information on the recorded charges for a communication when the 
communication is terminated. 

The present document is applicable to User Equipment (UE) and Application Servers (AS) which are intended to 
support the AOC supplementary services. 
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Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the terms and definitions given in 3GPP TS 22.173 [1] apply. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AOC Advice Of Charge 

AOC-D AOC During the call 

AOC-E AOC at the End of the call 

AOC-S AOC at call Set-up time 

AS Application Server 

CB Communication Barring 

CCBS Completion of Communication to Busy Subscriber. 

CD Communication Deflection 

CDIV Call Diversion 

CFB Communication Forwarding Busy 

CFNL Communication Forwarding on No Logged-in 

CFNRd Communication Forwarding Not Registered 

CFNRy Communication Forwarding No Reply 

CFU Communication Forwarding Unconditional 

CN Core Network 

CNR Completion of communication on No Reply 

CONF CONFerence calling 

CW Communication Waiting 

ECT Explicit Communication Transfer 

HOLD Communication HOLD 

IFC Initial Filter Criteria 

IM IP Multimedia 

IMS IP Multimedia Subsystem 

IP Internet Protocol 

ISDN Integrated Service Data Network 

MCID Malicious Communication IDentification 

MIME Multipurpose Internet Mail Extensions 

OIP Originating Identification Presentation 

OIR Originating Identification Restriction 

S-CSCF Serving-Call Session Control Function 

SIP Session Initiation Protocol 

TIP Terminating Identification Presentation 

TIR Terminating Identification Restriction 

UE User Equipment 



Advice Of Charge (AOC) 



4.1 



Introduction 



The Advice Of Charge (AOC) service allows the served user to be informed of IP Multimedia session related charging 
information. 
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4.2 Description 

4.2.1 General description 

The AOC service is limited to INVITE-initiated sessions. 

The AOC service is not meant to replace the charge metering inside the network which is considered to be correct in all 

cases. 

The charging information given shall relate to the charges incurred in the current network. 

4.2.2 Cinarging information at communication set-up time (AOC-S) 

When the AOC-S service is activated, the network shall provide the user with information about the charging rates at 
communication establishment. In addition, the network shall inform the served user if a change in charging rates takes 
place during the communication. 

4.3 Cinarging information during tine communication (AOC-D) 

When the AOC-D service is activated, the network shall provide the user with charging information for a 
communication during the active phase of this communication. The supplied charging information shall be provided as 
a cumulative charge incurred so far for the communication (i.e. charges recorded from the start of the communication 
and until the moment the charging information is sent to the served user), or as charging units. 

When the call is released, the network shall send the recorded charges for the communication to the served user. 

4.4 Cinarging information at the end of the communication 
(AOC-E) 

When the AOC-E service is activated, the network shall provide the served user with charging information indicating 
the recorded charges for a communication when this communication is released. 

4.5 Operational requirements 

4.5.1 Provision/withdrawal 

The AOC services shall be provided to the served user after prior arrangement with the service provider or, as a service 
provider option, be generally available. Withdrawal of these services shall be made on the served user's request or for 
service provider reasons. 

When available the AOC services shall be provided for all communications (permanent mode). 

4.5.2 Requirements on the originating network side 

No specific requirements are needed in the network. 

4.5.3 Requirements on the terminating network side 

No specific requirements are needed in the network. 

4.6 Coding requirements 

The INFO method according to IETF RFC 2976 [4] is needed in support of AOC-D. 
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The AOC XML schema is defined in annex D. The AOC XML schema shall be transported as a SIP MIME body. The 
MIME type for the AOC information is "application/vnd.etsi.aoc+xml" (see subclause 5.1). Any SIP message that 
transports a body with AOC information shall identify the payload as MIME type "application/vnd.etsi.aoc+xml", the 
MIME type associated with AOC information (see subclause 5.1), and shall identify in the "sv" or "schema version" 
parameter's value the versions of AOC XML Schema that can be used to validate the AOC information XML body 
(part). If both the "sv" and "schema version" parameters are present, then the P-CSCF shall ignore the value of the 
"schema version" parameter. The versions - of the MIME type associated with AOC information (see subclause 5.1) - 
indicated shall correspond with a value of the version attribute of the <schema> XML element of an AOC XML 
Schema (see e.g. annex D). 

4.7 Signalling requirements 
4.7.1 Activation/deactivation 

The AOC service is activated at provisioning and deactivated at withdrawal. 

4.7.1 A Registration/erasure 

The AOC service requires no registration. Erasure is not applicable. 

4.7.1 B Interrogation 

Interrogation of AOC is not applicable. 

4.7.2 Invocation and operation 

4.7.2.0 Introduction 

Basic communication procedures according to 3GPP TS 24.229 [2] shall apply, with the additions outlined in the 
subclauses below. 

4.7.2.1 Actions at the served UE 

The served UE shall support the INFO method and the AOC XML schema defined in annex D. 

If methods or responses are received which contain AOC information, this information may be rendered to the user. 

In addition to the procedures according to 3GPP TS 24.229 [2], the served UE shall include the Accept header field 
with: 

"application/vnd.etsi.aoc+xml", the MIME type associated with AOC information (see subclause 5.1), and 
indicate the versions of the AOC XML Schema it supports. The versions - of the MIME type associated with 
AOC information (see subclause 5.1) - indicated shall correspond with a value of the version attribute of the 
<schema> XML element of an AOC XML Schema (see e.g. annex D); and 

any other MIME type the served UE is willing and capable to accept. 

4.7.2.2 Actions at the AS of the served user 
4.7.2.2.0 General 

The AS shall assume that the served user's UE supports version 1.0 of the MIME type associated with AOC information 
(see subclause 5.1), if support for the MIME type associated with AOC information in the Accept header is not 
indicated. The versions - of the MIME type associated with AOC information (see subclause 5.1) - indicated shall 
correspond with a value of the version attribute of the <schema> XML element of an AOC XML Schema (see e.g. 
Annex D). 
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When sending AOC information, the AS shall encode this information according to the XML-schema defined in 
annex D. In addition, for this MIME body the AS shall: 

set the Content-Type header to "vnd.etsi.aocH-xml", the MIME type associated with AOC information (see 
subclause 5.1), and shall include in its "sv" or "schema version" parameter"s value the versions of AOC XML 
Schema that can be used to validate the AOC information XML body (part). If both the "sv" and 
"schemaversion" parameters are present, then the P-CSCF shall ignore the value of the "schema version" 
parameter. The versions - of the MIME type associated with AOC information (see subclause 5.1) - indicated 
shall correspond with a value of the version attribute of the <schema> XML element of an AOC XML Schema 
(see e.g. Annex D); and 

set the Content-Disposition to "render" with the "handling" parameter set to "optional". 

In the case the AOC information is transported in a message that is forwarded by the AS that contains already a content 
body, the AS shall generate a multipart/mixed MIME body containing two sub-parts: 

one with the AOC information; the Content-Type and Content-Disposition of this sub-part should be coded as 
specified for non-multipart bodies; 

one with the received body; headers describing the content of the received SIP message (e.g. Content-type) 
should be moved into the headers of the this subpart. 

In the case the AOC information is transported in a message that is forwarded by the AS, that contains already a content 
body and the served user's UE has not indicated support for multipart content, the AS shall forward the message 
unchanged. 

NOTE: The above subclause ensures that a communication setup is not affected in case a terminal does not 
support multipart content. 

4.7.2.2.1 Actions for AOC-S 

4.7.2.2.1 .1 Served user is the originating user 

When an INVITE request is received, and the served user is subscribed to AOC-S service, the AS shall either (network 
operator option) operate as a SIP proxy as specified in subclause 5.7.4 of 3GPP TS 24.229 [2] and in 
IETF RFC 3262 [5] and include the AOC information in the content body of a reliable Ixx provisional responses, or 
operate as a routing B2BUA as specified in subclause 5.7.5 of 3GPP TS 24.229 [2] and include the AOC information in 
the content body a 200 (OK) response forwarded by the AS. 

If the charging rates change during the communication, the AS shall send the AOC information to the UE of the served 
user in the content body of a mid-dialog request forwarded by the AS or an INFO request generated by the AS. 

NOTE: If no charging information is available, then the AS can, as a network option, stop the communication 
establishment before the session is confirmed by sending a 504 (Server Time-out) response to the 
originating user and a BYE request to the terminating side. The BYE request contains a Reason header 
field with a reason value with the protocol set to "SIP" and the cause set to "504" and optionally a reason 
value with the protocol set to "Q.850" and the cause set to "31". 

4.7.2.2.1 .2 Served user is the terminating user 

The AS shall operate as a routing B2BUA as specified in subclause 5.7.5 of 3GPP TS 24.229 [2]. 

When an INVITE request is received, and the served user is subscribed to the AOC-S service, the AS shall include the 
AOC information in the content body in the INVITE request before sending the INVITE request to the terminating UE. 

If the charging rates change during the communication, the AS shall send the AOC information to the UE of the served 
user in the content body of a mid-dialog request forwarded by the AS or an INFO request generated by the AS. 

NOTE: If no charging information is available, then the AS can, as a network option, not forward the 
communication invitation and send a 504 (Server Time-out) response to the originating side. 
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4.7.2.2.2 Actions for AOC-D 

The AS shall operate as a routing B2BUA as specified in subclause 5.7.5 of 3GPP TS 24.229 [2]. 

The procedures for AOC-D service at the AS are the same for the originating and the terminating user. 

If the user is subscribed to AOC-D service, the AS may provide charging information to the user at any moment during 
the active phase of the communication. When sending the charging information, the AS shall include the AOC 
information in the content body of a mid-dialog request or mid-dialog response forwarded by the AS to the served user 
or an INFO request to the served user generated by the AS. The supplied charging information shall be provided as a 
cumulative charge incurred so far for the communication (i.e. charges recorded from the start of the communication 
until the moment the charging information is sent to the served user). 

When the communication is terminated, the AS shall include the recorded AOC information for the communication in 
the content body of either the BYE request or the final response to the BYE request sent to the served user. If the 
communication is free of charge, then the AS shall indicate the charged amount as zero in the AOC information. 

4.7.2.2.3 Actions for AOC-E 

The AS shall operate as a SIP proxy as specified in subclause 5.7.4 of 3GPP TS 24.229 [2]. 

The procedures for AOC-E service at the AS are the same for the originating and the terminating user. 

If the user is subscribed to AOC-E service, when the communication is terminated the AS shall include the recorded 
AOC information for the communication in the content body of either the BYE request or the final response to the BYE 
request sent to the served user. If the communication is free of charge, then the AS shall indicate the charged amount as 
zero in the AOC information. 

4.8 Interaction with other services 

4.8.1 Communication Waiting (CW) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.8.2 Communication Hold (HOLD) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.8.3 Terminating Identification Presentation (TIP) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.8.4 Terminating Identification Restriction (TIR) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.8.5 Originating Identification Presentation (OIP) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.8.6 Originating Identification Restriction (OIR) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.8.7 CONFerence calling (CONF) 

No impact, i.e. neither service shall affect the operation of the other service. 
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NOTE: AOC information as result of a CONF invocation is out of scope the present document. 

4.8.8 Communication Diversion services (CDIV) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.8.9 Advice Of Cinarge (AOC) 

If the AOC-D and AOC-E services are activated for the same communication, at the end of the communication the 
network shall only send AOC-E type information. 

4.8.1 Completion of Communications to Busy Subscriber (CCBS) 
Completion of Communications by No Reply (CCNR) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.8.1 1 Malicious Communication IDentification (MCID) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.8.12 Anonymous Communication Rejection and Communication Barring 
(ACR/CB) 

No impact, i.e. neither service shall affect the operation of the other service. 

4.8.1 3 Explicit Communication Transfer (ECT) 

No impact, i.e. neither service shall affect the operation of the other service. 

NOTE: AOC information as result of an ECT invocation is out of scope of the present document. 

4.9 Interactions with other networks 

Not applicable. 

4. 1 Parameter values (timers) 

Not applicable. 

5 Extensions within the present document 

5.1 AOC information XML body 
5.1.1 General 

This subclause contains the AOC information XML body in XML format. The AOC information XML shall be valid 
against the AOC XML schema defined in Annex D. 

See subclause 5.L2 for the associated MIME type definition. 
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5.1.2 MIME type definition 

5.1.2.1 Introduction 

This subclause defines the MIME type for "application/vnd.etsi.aoc+xml". An AOC information XML Document can 
be identified with this media type. 

5.1.2.2 Syntax 

The following optional parameters are defined: 

"charset": the parameter has identical semantics to the charset parameter of the "appUcation/xml" media type as 
specified in IETF RFC 3023 [8]. 



"sv" or "schema version": the syntax for the "sv" or "schema version" parameter is specified in table 2: 
Table 2: Syntax of the "sv" or "schemaversion" parameter 

m-parameter /= {"sv" / "schemaversion") EQUAL LDQUOT [ sv-value-list ] RDQUOT 

sv-value-list = sv-value-range *{ "," sv-value ) 

sv-value-range = sv-value [ "-" sv-value ] 

sv-value = number / token 

number = 1*DIGIT [ " . " 1*DIGIT ] 



The BNF for m-parameter is taken from IETF RFC 3261 [7] and modified accordingly. 

5.1.2.3 Operation 

The encoding considerations for "application/vnd.etsi.aoc+xml" are identical to those of "application/xml" as described 
in IETF RFC 3023 [8]. 

The "sv" or "schemaversion" parameter's value is used to indicate: 

the versions of the AOC information XML schema that can be used to validate the AOC information XML body 
(if the MIME type and parameter are present in the Content-Type header); or 

the accepted versions of the AOC information XML body (if the MIME type and parameter are present in the 
Accept header). If the "sv" or "schemaversion" parameter"s value is empty, no versions of the of the AOC 
information XML schema are supported. 

If the "sv" and "schemaversion" parameter are absent, it shall be assumed that version LO of the XML Schema for the 
AOC information XML body is supported. 
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Annex A (informative): 
Signalling flows 

A.1 Introduction 

The service is divided into two aspects: 

a) Application Server gathers information: this is out of scope of the present document. 

b) User is provided the AOC Information. 

A.2 User originating AOC service 

A.2.1 AOC-S 

A.2.1 .1 AOC-S with information in reliable 1xx responses 



UE-A 



CSCFs O 



-1. INVITE- 



4. 183 Session 
progress 
[AoC info] 

--5. PRACK-- 



-8. 200OK- 



-2. INVITE 



3. 183 Session 
progress 
[AoC info] 



6. PRACK 
-7. 200 OK 

-9. INVITE 



ASO 


► 

an 

---► 













CSCFs T 



-10. INVITE - 



-14. 200 OK - 
-15. 200OK- 



13. 200OK- 



UE-B 



-11. INVITE- 
-12. 200OK- 



■< 16. 200 OK 

Figure A.2. 1.1: Charging info during session set-up (originating side) 

Figure A.2. 1.1 shows one ordering of the messages. Message 3 and message 9 can be sent at the same moment. 

General 

The AOC information is provided for every communication. This is provisioned in the AS. The AOC information is 
sent to UE-A in a 183 (Session Progress) response. 
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Call flows 

1 to 5 and 1 to 2 The communication is initiated by UE-A by sending an INVITE request. The Request URI will 
include the URI of UE-B. After IFC evaluation in the S-CSCF the INVITE request is routed to the Originating AS. The 
INVITE request will indicate support for lOOrel extension. 

3 to 8 The Originating AS sends the AOC information to UE-A in a reliable 183 (Session Progress) response. 

9 to 1 1 The INVITE request is sent to UE-B. 

12 to 16 The UE-B answers the communication. The 200 (OK) response is generated by UE-B. 

A.2.1 .2 AOC-S with AOC information in a 200 (OK) response 



UE-A 



CSCFs 



ASO 



CSCFs T 



UE-B 



-1, INVITE - 



-2. INVITE- 
-3. INVITE - 



-4. INVITE - 



-7. 200 OK- 



10. 200 OK 
[AoC Info] 

— 11. ACK— 



-8. 200 OK- 

9. 200 OK 
[AoC Info] 



-12. ACK- 
-13. ACK- 



-14.ACK- 



-5. INVITE- 
-6. 200 OK- 



15. ACK— 



Figure A.2.1. 2: Charging info in 200 (OK) response during session set-up (originating side) 

Figure A.2.1. 2 shows one ordering of the messages. 

General 

The AOC information is provided for every call. This is provisioned in the AS. The AOC information is sent to UE-A 
in 200 (OK) response (to INVITE request) after receiving a 200 (OK) response (to the INVITE request) from UE-B. 

Call flows 

1-5 The call is initiated by UE-A by sending an INVITE request. The Request URI will include the URI of UE-B. The 
INVITE request is routed via the Originating AS to UE-B. 

6-10 UE-B answers the call. The 200 (OK) response is generated by UE-B. The Originating AS sends the AOC 
information to UE-A in this 200 (OK) response. 

11-15 UE-A sends an ACK request to UE-B and the session is established. 
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A.2.2 AOC-D 



UE-A 



CSCFs-0 



2. INFO 
[AoC info] 

-3. 200 OK- 



AS-0 



CSCFs-T 



'RTP media' 



1. INFO 
[AoC info]" 



-4. 200 OK- 



UE-B 



Figure A.2.2. 1 : Charging info during the communication 

This can be a continuation of figures A. 2. 1.1 or A. 2. 1.2. 

Call flow 

1-4 When the charging rate is changes, an INFO request is send from the Originating AS to UE-A. The AOC 
information is included in the INFO request. 

A.2.3 AOC-E 

Calling party clears 



UE-A 



CSCFs-0 



-1.BYE- 



10. 200 OK 
" [AoC info] ' 



AS-0 



CSCFs-T 



UE-B 



RTF media — 



-2. BYE- 
-3. BYE- 



-4.BYE- 



-7. 200OK- 



-8. 200OK- 

9. 200 OK 
"[AoC info] 



—5. BYE — 
-6. 200OK- 



Figure A.2.3. 1 : Calling party clears 

The AOC information is provided for every communication after the communication has finished. This is provisioned 
in the AS. The AOC information is sent to the terminal in a 200 (OK) response (to the BYE request), which is 
originated from UE-B. 

Call Flow 

The communication has been set up as a normal communication. 
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1-5 UE-A generates a BYE request to terminate the session, which is routed to UE-B. 

6-10 UE-B sends a 200 (OK) response (to BYE request) towards UE-A. When the Originating AS receives the 200 
(OK) response, it adds the AOC information to the 200 (OK) response (to the BYE request). 

Called party clears 



UE.A 



CSCFs-0 



AS-0 



5. BYE 
[AoC info]" 

-6. 200OK- 



RTP media — 



-2. BYE- 



-3. BYE- 



4. BYE 
[AoC info]" 



-7. 200 OK- 
-8. 200 OK- 



-9. 200 OK- 



CSCFs-T 



UE-B 



-1. BYE- 



-10. 200OK- 



Figure A.2.3.2: Called party clears 

The AOC information is provided for every communication after the communication has finished. This is provisioned 
in the AS. The charging info is sent to the terminal in a BYE request, which is originated from UE-B. 

Call Flow 

The communication has been set-up as a normal communication. 

1-5 UE-B generates a BYE request to terminate the session, which is routed to the UE-A. When the Originating AS 
receives the BYE request, it adds the AOC information to the BYE request. 

6-. 10 UE-A sends a 200 (OK) response (to the BYE request) towards UE-B. 
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A.3 User terminating AOC service 



A.3.1 AOC-S 



UE-A 



CSCFs 



ASO 



-1. INVITE - 



14. 183 Session 
Progress 

-15. PRACK-- 



28. 200 OK- 



-35. 200OK(INVITE)- 
36. ACK 



AST 



CSCFs T 



UE-B 



-2.INVITE- 
-3. INVITE- 



-4. INVITE - 



12. 183 Session 
Progress 

13. 183 Session 
Progress 



-16. PRACK- 
17. PRACK - 



11. 183 Session 
Progress 



5. INVITE 

-6. INVITE [AoC Info]- 



9. 183 Session_ 
Progress 

10. 183 Session 
Progress 



-18. PRACK- 



19. PRACK - 
-20. PRACK- 

23. 200 OK - 
-24. 200 OK- 



-25.200OK- 



-26. 200 OK- 
-27. 200 OK - 



-30.200OK(INVITE)- 
-31. 200 OK (INVITE - 



-32. 200 OK (INVITE) 



-33. 200 OK (iNViTE)- 
-34.200OK(iNViTE)- 



-37. ACK- 



38. ACK- 



-39.ACK- 



-40.ACK- 
-41. ACK- 



-7. INVITE [AoC Info]- 

8. 183 Session 

Progress 



-21. PRACK- 
22. 200 OK 



-29. 200OK(INVITE)- 



-42.ACK- 



Figure A.3.1. 1 : Charging info during session set-up on the terminating side 
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General 

The AOC information is provided for every call. This is provisioned in the AS. The AOC information is sent to the 
terminal in an INVITE request. Since this is a service that is charged an acknowledgement is required to ensure that the 
charging info is transferred. 

Call flows 

1-5 The call is initiated by UE-A by sending an INVITE request. The Request URI will include the URI of UE-B. The 
INVITE request is routed to the Originating AS and the Terminating AS. The INVITE request will indicate that lOOrel 
extension is supported. 

6-7 The Terminating AS will include the charging info in the INVITE request sent to the UE-B. 

8-28 UE-B sends a reliable provisional response to indicate that INVITE request is being processed. 

29-35 UE-B answers with a 200 (OK) response (to the INVITE request) and sends it to UE-A. 

36-42 UE-A sends an ACK request to acknowledge the 200 (OK) response (to the INVITE request) and the session is 
established successfully. 

A.3.2 AOC-D 



UE-A 



CSCFs-0 



AS-0 



AS-T 



CSCFs-T 



UE-B 



1.INF0 
[AoC info] 



-4. 200 OK- 



2. INFO 
[AoC info] 

-3, 200OK- 



Figure A.3.2. 1 : Charging info during the call (terminating) 

This can be a continuation of figures A. 3. 1.1 or A. 3. 1.2.1. 

Call flows 

1-4 When the charging rate is changes, an INFO request is send from the terminating AS to UE-B. The AOC 
information is included in the INFO request. 
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A.3.3 AOC-E 

Calling party clears 



UE-A 



CSCFs-0 



CSCFs-T 



RTP media- 



AS-T 



UE-B 



-1.BYE- 



-2. BYE- 



-9. 200 OK- 



-3. BYE- 



4.BYE 
[AoCinfo]" 



5. BYE 
[AoC info] 

-6. 200 OK- 



-7. 200 OK- 
-8. 200 OK- 



10. 200 OK - 



Figure A.3.3. 1 : Calling party clears 

The AOC information is provided for every communication after the communication has finished. This is provisioned 
in the AS. The AOC information is sent to the terminating user in the BYE request which is originated from UE-A. 

Call Flow 

The communication has been set up as a normal communication. 

1-5 UE-A generates a BYE request to terminate the session, which is routed to the UE-B. When the Terminating AS 
receives the BYE request, it adds the AOC information. 

6-10 UE-B sends a 200 (OK) response towards UE-A. 
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Called party clears 



UE.A 



CSCFs-0 



—5. BYE — 
-6. 200OK- 



CSCFs-T 



RTP media — 



AS-T 



-4. BYE- 



-7. 200 OK- 



1.BYE- 

-2. BYE ► 



-3. BYE- 



-8. 200 OK- 

9. 200 OK 
[AoCinfo]" 



UE-B 



10. 200 OK 
" [AoC info] ' 



Figure A.3.3.2: Called party clears 

The AOC information is provided for every communication after the communication has finished. This is provisioned 
in the AS. The charging info is sent to the terminating user in the 200 (OK) response, which is originated from UE-A. 

Call Flow 

The communication has been set-up as a normal communication. 

1-5 UE-B generates a BYE request to terminate the session, which is routed to UE-A. 

6-. 10 UE-A sends a 200 (OK) response towards UE-B. When the Terminating AS receives the 200 (OK) response, it 
adds the AOC information. 
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Annex B (informative): 
Example of Filter Criteria 



This annex provides an example of a filter criterion that triggers SIP requests that are subject to initial filter criteria 
evaluation. 

An example of an IFC when the AOC service is active at the originating S-CSCF is: 

- Method: INVITE. 
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Annex C (normative): 
Charging Information Elements 

C.1 General 

This annex describes the charging information to be provided to the served user. 

02 AOC-S 

The AOC-S service provides tariff information at the start of the call or when tariff changes occur during the call. 

C.2.1 Charged Items 

AOC-S can provide a list of charged items or a special charging arrangement. 
Following charged items are thought applicable: 

basic communication; 

communication attempt; 

communication setup; 

operation of supplementary services. 
The special charging arrangement excludes all other charged items and is therefore mentioned separately. 

C.2.1 .1 Charged Item: basic communication 

This expresses the rate for the basic communication. 
The rate shall be expressed as: 

price per time unit and time unit (see subclause C.2.2. 1); or 

free of charge (see subclause C.2.2. 2); or 

flat rate (see subclause C.2.2. 3); or 

special charging code (see subclause C.2.2.4); or 

not available (see subclause C. 2.2.6). 

C.2.1 .2 Charged Item: communication attempt 

This expresses the cost of a communication attempt. 
The cost shall be expressed as: 

free of charge (see subclause C.2.2. 2); or 

flat rate (see subclause C.2.2. 3); or 

special charging code (see subclause C.2.2.4); or 

not available (see subclause C.2.2. 6). 
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C.2.1 .3 Charged Item: communication setup 

This expresses the cost of a communication setup. 
The cost shall be expressed as: 

free of charge (see subclause C. 2.2.2); or 

flat rate (see subclause C.2.2.3); or 

special charging code (see subclause C.2.2.4); or 

not available (see subclause C. 2.2.6). 

C.2.1 .4 CInarged Item: operation of services 

This expresses the cost induced by the execution of services. 
The cost shall be expressed as: 

price per time unit and time unit (see subclause C.2.2. 1); or 

free of charge (see subclause C. 2.2.2); or 

flat rate (see subclause C.2.2.3); or 

special charging code (see subclause C.2.2.4); or 

not available (see subclause C. 2.2.6). 

C.2.1 .5 Special Charging Arrangement 

This expresses that a special charging arrangement exists for calculating the costs of the call. 
The cost shall be expressed as: 

special charging code (see subclause C.2.2.4). 

C.2.2 Expressing Charging Rates 

AOC-S can express charging rate as: 

price per time unit and time unit (see subclause C.2.2. 1); or 

free of charge (see subclause C. 2.2.2); or 

flat rate (see subclause C.2.2.3); or 

special charging code (see subclause C.2.2.4); 

charging unit (see subclause C.2.2. 5); or 

not available (see subclause C.2.2. 6). 

C.2.2. 1 Duration charge: Price per time unit, and unit time 

Duration charge shall contain the following elements: 
currency identifier (see subclause C.5.4); and 
currency amount (see subclause C.5.5); and 
length of time unit (see subclause C.5.6); and 
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- type of charging (see subclause C.5.8). 
and additionally it may contain the following element: 
granularity (see subclause C.5.7). 

C.2.2.2 Specific: free of cinarge 

This rate represents a free charge. 

C. 2.2.3 Specific: flat rate 

It shall be expressed as: 

currency identifier (see subclause C.5.4); 
currency amount (see subclause C.5.5). 

C.2.2.4 Specific: special charging code N. 

It shall be expressed as an integer between 1..10. 

C.2.2.5 Charging unit 

Charging unit shall contain the following elements: 
currency identifier (see subclause C.5.4); and 
currency amount (see subclause C.5.5). 

C.2.2.6 Not available 

Expresses that the charging information is not available. 
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C.3 AOC-D 

The AOC-D service provides information about the recorded charges during the active phase of a call. 
The information shall contain the following elements: 

type of charging information (see subclause C.3.1); and 

recorded charges (see subclause C.3. 2). 

and additionally it may contain the following element: 

- billing identification (see subclause C.3. 3). 

C.3.1 Type of charging information 

Type of charging information shall have one of the following values: 
subtotal charges; or 
total charges. 



£75/ 



3GPP TS 24.647 version 9.0.0 Release 9 27 ETSI TS 1 24 647 V9.0.0 (201 0-01 ) 

C.3.2 Recorded charges 

Recorded charges shall be expressed as one of the following elements: 

recorded number of currency units or charging units (see subclause C.5.9); or 
free of charge; or 
not available. 

C.3.3 Billing identification for AOC-D 

It shall be expressed as one of the following values: 
normal charging (default); or 
reverse charging; or 
- credit card charging. 

04 AOC-E 

The AOC-E service provides information about the recorded charges for a call when it is terminated. 
The information consists of: 

recorded charges (see subclause C.3.2) 

billing identification (see subclause C.4.1). 

C.4.1 Billing identification for AOC-E 

It shall be expressed as one of the following values: 
normal charging (default); or 
reverse charging; or 
credit card charging; 
call forwarding unconditional; 
call forwarding busy; 
call forwarding noreply; 
call deflection; 
call transfer. 

C.5 Common types/information elements 
C.5.1 Time unit 

Time unit shall be an integer value. 
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C.5.2 Decimal 

Decimal shall be a decimal value. 

C.5.3 Scale 

The scale of time units shall have one of the following values: 

- 0,01 s; 

- 0,1 s; 

- 1 s; 

- 10 s; 

1 min; 
1 hour; or 
24 hours. 

C.5.4 Currency identifier 

It shall be a string specifying the used currency or a charging unit identifier. 

C.5.5 Currency amount 

It shall be expressed as the value of decimal (see subclause C.5.2). 

C.5.6 Length of time unit 

It shall be expressed as value of integer x scale: 
time unit (see subclause C.5.1); and 

- scale (see subclause C.5.3). 

C.5.7 Granularity 

This specifies the time unit applied for calculation of charges by the network. 
It shall be expressed as value of integer x scale: 

time unit (see subclause C.5.1); and 

scale (see subclause C.5.3). 

C.5.8 Type of charging 

Type of charging shall have one of the values of "step function" or "continuous". 

C.5.9 Recorded number of currency units 

It shall be expressed as: 

currency identifier (see subclause C.5.4); 
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currency amount (see subclause C.5.5). 
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Annex D (normative): 

AOC XML Schema, version 1 .0: 



This annex defines the XML Schema to be used for providing the charging information described in annex C in the SIP 
methods to the served user. 

The application/vnd.etsi.aoc+xml MIME type used to provide the charging information requested by the served user 
shall be coded as following described: 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema targetNamespace=" http : //uri . etsi . org/ngn/params/xml/simservs/aoc " 

xmlns=" http : //uri . etsi .org/ngn/params/xml/simservs/aoc " xmlns :xs="http : //www. w3 . org/2 001/XMLSchema" 

elementFormDefault=" qualified" attributeFormDefault=" unqualified" version="l . 0" > 

<xs : import namespace="http : //www. w3 .org/XML/ 1998 /namespace" 
schemaLocation="http : //www. w3 . org/2 01/xml .xsd"/> 
<xs : annotation> 

<xs : documentation xml : lang="en" > 
XML Schema Definition to the charging information related to the Advice of Charge service. 
</xs : documentation> 
</xs : annotation> 

<xs: element name="aoc" type="aocType"/> 

<xs : complexType name="aocType" > 
<xs : sequence> 

<xs:element name="aoc-s" type="aoc-sType" minOccurs=" 0"/> 
<xs:element name="aoc-d" type="aoc-dType" minOccurs=" 0"/> 
<xs:element name="aoc-e" type="aoc-eType" minOccurs="0"/> 
<xs : any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> 
</xs : sequence> 
<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType> 

<!-- xs : sequence is changed to xs: choice --> 
<xs : complexType name="aoc-sType" > 
<xs : choice> 

<xs:element name="special-arrangement" type="xs : token" /> 
<xs: element name=" charged- items" type=" charged- itemsType"/> 

<xs : any namespace="##other" processContents="lax" minOccurs=" 0" 
maxOc cur s = " unbounded " / > 
</xs : choice> 

<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType > 

<xs : complexType name="aoc-dType" > 
<xs : sequence> 

<xs: element name=" charging- info" type=" charging- infoType" /> 
<xs: element name=" recorded- charges" type=" recorded- chargesType" /> 
<xs:element name="billing-id" type="billind-idType" minOccurs=" 0" /> 
<xs : any namespace="##other" processContents="lax" minOccurs=" 0" 
maxOccur s = " unbounded " / > 

</xs : sequence> 
<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType> 

<xs : complexType name="aoc-eType" > 
<xs : sequence> 

<xs: element name=" recorded- charges" type=" recorded- chargesType" /> 
<xs:element name="billing-id" type="billind-idType" minOccurs=" 0" /> 
<xs : any namespace="##other" processContents="lax" minOccurs=" 0" 
maxOccur s = " unbounded " / > 

</xs : sequence> 
<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType> 

<xs : complexType name=" charged- itemsType" > 
<xs : sequence> 

<xs:element name="basic" type="basicType" minOccurs=" 0"/> 

<xs : element name="communication-attempt" type="communication-attemptType" 
minOccurs= " " / > 
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<xs : element name="communication-setup" type="communication-setupType" 
minOccur s = " " / > 

<xs:element name=" services" type="servicesType" minOccurs=" 0" /> 
<xs : any namespace="##other" processContents="lax" minOccurs=" 0" 
maxOc cur s = " unbounded " / > 

</xs : sequence> 
<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType> 

<xs : complexType name="basicType" > 
<xs : sequence> 

<xs:element name="price-time" type="price-timeType" minOccurs=" 0" 
maxOccurs="unbounded" /> 

<xs:element name="f lat-rate" type=" currency- id- amountType" minOccurs="0" /> 
<xs:element name="f ree-charge" type="emptyType" minOccurs="0" /> 
<xs:element name="special-code" type="xs : token" minOccurs="0" /> 
<xs:element name="not-available" type="emptyType" minOccurs="0" /> 
</xs : sequence> 
</xs : complexType > 

<xs : complexType name="communication-attemptType" > 
<xs : sequence> 

<xs:element name="f lat-rate" type=" currency- id- amountType" minOccurs=" 0" /> 
<xs:element name="f ree-charge" type="emptyType" minOccurs="0" /> 
<xs:element name="special-code" type="xs : token" minOccurs="0" /> 
<xs:element name="not-available" type="emptyType" minOccurs="0" /> 
</xs : sequence> 
</xs : complexType > 

<xs : complexType name=" communication- setupType" > 
<xs : sequence> 

<xs:element name="f lat-rate" type=" currency- id- amountType" minOccurs="0" /> 
<xs:element name="f ree-charge" type="emptyType" minOccurs="0" /> 
<xs:element name="special-code" type="xs : token" minOccurs="0" /> 
<xs:element name="not-available" type="emptyType" minOccurs=" 0" /> 
</xs : sequence> 
</xs : complexType > 

<xs : complexType name="servicesType" > 
<xs : sequence> 

<xs:element name="price-time" type="price-timeType" minOccurs="0" /> 
<xs:element name="f lat-rate" type=" currency- id- amountType" minOccurs="0" /> 
<xs:element name="f ree-charge" type="emptyType" minOccurs="0" /> 
<xs:element name="special-code" type="xs : token" minOccurs=" 0" /> 
<xs:element name="not-available" type="emptyType" minOccurs=" 0" /> 
</xs : sequence> 
</xs : complexType> 

<!-- length-time-unit: type="timeType" {another possibilty is to keep length-time-unit with 
type="xs : duration" ) 

granularity: type="timeType" {another possibility is type="xs : duration" ) 
{xs : duration: the minimum resolution is second) 
- - > 

<xs : complexType name="price-timeType" > 
<xs : sequence> 

<xs: element name=" currency- id" type="xs : token" minOccurs=" 0"/> 
<!-- The currency- id shall be coded according to ISO 4217 [3] or set to the value 
"UNIT" for the sending of charging units. --> 

<xs:element name=" currency- amount" type="xs : decimal" minOccurs=" 0" /> 
<xs:element name="length-time-unit" type="timeType" minOccurs=" 0" /> 
<xs:element name=" charging- type" type=" charging- typeType" minOccurs=" 0" /> 
<xs:element name="granularity" type="timeType" minOccurs=" 0" /> 
</xs : sequence> 
</xs : complexType > 

<xs : complexType name=" currency- id- amountType" > 
<xs : sequence> 

<xs: element name=" currency- id" type="xs : token" minOccurs=" 0"/> 
<!-- The currency- id shall be coded according to ISO 4217 [3] or set to the value 
"UNIT" for the sending of charging units. --> 

<xs:element name =" currency- amount" type="xs : decimal" minOccurs=" 0" /> 
</xs : sequence> 
</xs : complexType> 

<!-- timeType is represented with time-unit {unsigned int) * scale {enum) --> 
<xs : complexType name="timeType" > 
<xs : sequence> 

<xs:element name="time-unit" type="xs :unsignedInt"/> 
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<xs:element name="scale" type="scaleType"/> 
</xs : sequence> 
</xs : complexType> 

<xs : simpleType name="scaleType" > 

<xs : restriction base="xs : token" > 

<xs : enumeration value="one-hundreth-second"/> 

<xs : enumeration value=" one- tenth- second" /> 

<xs : enumeration value=" one- second" /> 

<xs : enumeration value=" ten- seconds "/> 

<xs : enumeration value= "one-minute "/> 

<xs : enumeration value=" one- hour" /> 

<xs : enumeration value= " twenty- four-hours"/> 
</xs : restriction> 
</xs : simpleType> 
<!-- end of timeType definition --> 

<xs : complexType name= " emptyType " > 
<xs : complexContent> 

<xs : restriction base="xs : anyType"/> 
</xs : complexContent> 
</xs : complexType> 

<!-- simplified --> 

<xs : simpleType name=" charging- infoType" > 
<xs : restriction base="xs : token" > 

<xs : enumeration value="total" /> 
<xs : enumeration value=" subtotal" /> 
</xs : restriction> 
</xs : simpleType> 

<!-- xs : sequence is changed to xs: choice --> 
<xs : complexType name=" recorded- chargesType" > 
<xs : choice> 

<xs : element name= " recorded- currency-unit s " type= " currency- id- amountType " / > 
<xs:element name="f ree-charge" type=" emptyType" /> 
<xs:element name="not-available" type=" emptyType" /> 
</xs : choice> 
</xs : complexType> 

<xs : simpleType name="billind-idType" > 
<xs : restriction base="xs : string" > 

<xs : enumeration value=" normal- charging" /> 

<xs : enumeration value=" reverse- charging" /> 

<xs : enumeration value=" credit- card" /> 

<xs : enumeration value="cfu"/> 

<xs : enumeration value="cfb"/> 

<xs : enumeration value="cfnr"/> 

<xs : enumeration value="cd"/> 

<xs : enumeration value="ct"/> 
</xs : restriction> 
</xs : simpleType> 

<xs : simpleType name=" charging- typeType" > 
<xs : restriction base="xs : string" > 

<xs : enumeration value="step-functon" /> 
<xs : enumeration value=" continuous" /> 
</xs : restriction> 
</xs : simpleType> 
</xs : schema> 
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Annex E (informative): 
lANA Registration templates 

E.1 lANA registry for Application Media Types 

E.1 .1 lANA Registration template for application/vnd.etsi.aoc+xml 

NOTE: IETF RFC 4288 [9], section 9, states the process that appHes in case of changes to the registry of media 
types. Any future changes to the format or to annex E. 1 . 1 would invoke this procedure. 

MIME media type name: 

application 

MIME subtype name: 

vnd.etsi.aoc+xml 

Required parameters: 

None 

Optional parameters: 

"charset" the parameter has identical semantics to the charset parameter of the "application/xml" media type as 
specified in IETF RFC 3023 [8]. 

"sv" or "schemaversion" the parameter's value is used to indicate: 

the versions of the SIP AOC information XML schema that can be used to validate the AOC information XML 
body (if the MIME type and parameter are present in the Content-Type header field) or 

the accepted versions of the AOC information XML body (if the MIME type and parameter are present in the 
Accept header field). 

If the "sv" and "schemaversion" parameter are absent, it shall be assumed that version 1.0 of the AOC information 
XML body is supported. 

Encoding considerations: 

Same as encoding considerations of application/xml as specified in IETF RFC 3023 [8] 

Security considerations: 

Same as general security considerations for application/xml as specified in section 10 of IETF RFC 3023 [8]. 

In addition, this content type provides a format for exchanging information in SIP, so the security considerations from 
IETF RFC 3261 [7] apply. 

Interoperability considerations: 

Same as Interoperability considerations as specified in section 3.1 of IETF RFC 3023 [8]. 

If both "sv" and "schemaversion" are specified, then the value of "schemaversion" MUST be ignored 

Published specification: 

3GPP TS 24.647: "Advice Of Charge (AOC) using IPMulfimedia (IM) Core Network (CN) subsystem", as published 
in subclause E.1.1, version 8.2.0. 

Available via <http://www.3gpp.org/specs/numbering.htm>. 
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Applications which use this media: 

Applications that use the 3GPP IP multimedia (IM) Core Network (CN) subsystem as defined by 3GPP. 

Intended usage: 

COMMON 

Additional information : 

1 . Magic number(s) : none 

2. File extension(s) : none 

3. Macintosh file type code : none 

4. Object Identifiers: none 
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Annex F (informative): 
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